-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Core: Add error categorization framework #23653
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only reviewed the README, but I'm loving this work! Great job, Yann! 👏
bdc0d3e
to
eb877e1
Compare
export enum Category { | ||
CLI = 'CLI', | ||
CLI_INIT = 'CLI_INIT', | ||
CLI_AUTOMIGRATE = 'CLI_AUTOMIGRATE', | ||
CLI_UPGRADE = 'CLI_UPGRADE', | ||
CLI_ADD = 'CLI_ADD', | ||
CODEMOD = 'CODEMOD', | ||
CORE_SERVER = 'CORE-SERVER', | ||
CSF_PLUGIN = 'CSF-PLUGIN', | ||
CSF_TOOLS = 'CSF-TOOLS', | ||
NODE_LOGGER = 'NODE-LOGGER', | ||
TELEMETRY = 'TELEMETRY', | ||
BUILDER_MANAGER = 'BUILDER-MANAGER', | ||
BUILDER_VITE = 'BUILDER-VITE', | ||
BUILDER_WEBPACK5 = 'BUILDER-WEBPACK5', | ||
SOURCE_LOADER = 'SOURCE-LOADER', | ||
POSTINSTALL = 'POSTINSTALL', | ||
DOCS_TOOLS = 'DOCS-TOOLS', | ||
CORE_WEBPACK = 'CORE-WEBPACK', | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking that this category
should not be a field of StorybookError
, but should be should be passed to telemetry at the point where the error is caught.
For example, a function such as readConfig
from @storybook/csf-tools
will throw all kind of errors, but we likely want to know in telemetry more about the context where this function is called. As it can be called in codemods
, the eslint-plugin
, build
, init
, dev
etc.
Also, I'm kind of thinking that the boolean telemetry
should not be part of the StorybookError
class, but is something that is also context
dependent. As for example, I don't think we might not want to send telemetry for the eslint plugin, as it can be used independent of storybook (for other integrations)?
Maybe we should just maintain a list of code
's that we want telemetry for?
I guess you could say that telemetry
is just a different concern all together than throwing errors. For example, when you use composeStories
outside of storybook, or when used by other integrators, it is kind of weird that the Error
that we throw contains a telemetry
boolean.
1559ed2
to
2df20ed
Compare
2df20ed
to
f21cf3a
Compare
Removed dependencies detected. Learn more about Socket for GitHub ↗︎ 🚮 Removed packages: telejson@7.1.0 |
c66cf40
to
7192433
Compare
Closes #23511
What I did
This PR proposes a new way to write and throw errors in Storybook.
For more details, please check the README included in this PR.
Checklist
MIGRATION.MD
Maintainers
ci:normal
,ci:merged
orci:daily
GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/lib/cli/src/sandbox-templates.ts
["cleanup", "BREAKING CHANGE", "feature request", "bug", "build", "documentation", "maintenance", "dependencies", "other"]
🦋 Canary release
This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the
@storybookjs/core
team here.core team members can create a canary release here or locally with
gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>